Kubernetes 核心维护者应该权衡提议的新功能的好处与它们带来的额外复杂性，Kubernetes 联合创始人在今年的 KubeCon 上建议。
芝加哥——顶级的 Kubernetes 工程师们一致认为：K8s 对于最终用户甚至核心维护者来说都太复杂了。是时候将复杂性纳入预算了。
在本周的 Kubecon+CloudNativeCon 大会上，Kubernetes 联合创始人兼 Google 杰出软件工程师 Tim Hockin 在周四的主题演讲中回顾了 Kubernetes 的前九年（半）以及开源软件的未来。Kubernetes 可能已经开始主要为高度可扩展的 Web 应用程序提供支持，但现在它正日益成为更复杂工作（例如机器学习推理）的首选平台，这意味着将 K8s 扩展到更多用例的压力正在显着增加。
为了帮助他的演讲，Hockin 询问了云原生社区的其他人，他们认为 Kubernetes 面临的最紧迫的挑战是什么。正如您现在可能已经猜到的那样，一个反复出现的主题是努力解决部署和维护容器编排引擎有时令人生畏的复杂性。
有人甚至说这是K8s的“最大的生存威胁”。
“有些东西必须给予，”霍金说。在一定时间内，我们可以将有限的复杂性吸收到项目中，“他说。越复杂，核心维护者在未来轻松进行更改的敏捷性就越低。
同时，软件越复杂，用户对它的抵制就越大。
围绕 Kubernetes 的软件是社区驱动的：到目前为止，已经有超过 74,000 名贡献者加入了该项目。第一代用户对 K8s 产生了兴趣，许多人努力让它变得更好。
但随着新用户的不断加入，他们将不可避免地对 Kubernetes 的工作方式产生兴趣。因此，维护者有责任让它更易于使用，Hockin指出。
“我们添加的东西越复杂，我们消耗的预算就越多。当预算用完时，坏事就会发生，“他说。创新停止了，用户转向了其他解决方案。
因此，Kubernetes 项目经理需要将复杂性视为可以利用的有限资源：某种“复杂性预算”。
霍金承认，他不知道如何衡量一个软件的复杂性，更不用说最终用户在处理复杂软件时的耐心了。
然而，他指出，工程师通常知道他们何时在预算上超支。因此，在考虑添加新功能时，他们必须问一个问题：我们是否有足够的复杂性预算来负担？这是我们应该花有限的预算吗？
工程师工作的一部分是权衡任何决策的利弊，新功能可能带来的额外复杂性应该是要评估的一个因素。
对代码库的一些增强可能会在软件的某些方面带来 5% 的性能改进，但如果它为维护者带来了更多的内部复杂性，那么它是否值得。如果一个 API 被改变以满足一个利基用例，是否值得让所有其他用户承担这种改变的负担？
“提高标准需要我们所有人愿意说不，愿意对我们真正想要的东西说不，那些不是坏主意的事情，那些本身看起来显而易见和容易的事情。老实说，公司付钱给我们的东西可能真的想要，“他说。
通过对某些提案说“不”，可以在复杂性预算中留出一些空间，以处理未来更相关的项目。
“我们必须对今天的事情说'不'，这样我们明天就可以做有趣的事情，”霍金说。
Kubernetes 还有很多工作要做，但这并不意味着所有工作都需要立即完成。Hockin 说，我们都习惯于总是认为越多越好，但 Kubernetes 现在可能会遇到少等于多的情况。
正如有人向 Hockin 建议的那样：为了保持活力，Kubernetes 应该保持未完成。